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(57) Abstract: Methods and apparatus for providing a central- 
ized source of session keys to be shared by a Home Agent and 
a Mobile Node are disclosed. In accordance with one aspect of 
the invention, a Mobile Node registers with a Home Agent sup- 
porting Mobile IP by sending a registration request to the Home 
Agent. The Home Agent sends a request message (e.g., access- 
request message) to a AAA server, the request message identi- 
fying the Mobile Node. The AAA server then derives key infor- 
mation from a key or password associated with the Mobile Node. 
The AAA server then sends a reply message (e.g., access-reply 
message) to the Home Agent, the reply message including the 
key information associated with the Mobile Node, thereby en- 
abling the Home Agent to derive a shared key to be shared be- 
tween the Mobile Node and the Home Agent from the key infor- 
mation. The Home Agent derives a key from the key informa- 
tion, the key being a shared key between the Mobile Node and 
the Home Agent A registration reply is then sent to the Mobile 
Node. When the Mobile Node receives a registration reply from 
the Home Agent, the registration reply indicates that the Mobile 
Node is to derive a key to be shared between the Mobile Node 
and the Home Agent The Mobile Node then derives a key to be 
shared between the Mobile Node and the Home Agent from key 
information stored at the Mobile Node. The Mobile Node may 
initiate "re-keying** by sending a subsequent registration request 
to the Home Agent 
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METHODS AND APPARATUS FOR DYNAMIC SESSION KEY 
GENERATION AND REKEYING IN MOBILE IP 

5 BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present inventioii relates to Mobile IP network technology. More 
particularly, the present invention relates to performing dynamic session key 
generation in Mobile IP, 

10 2. Description of the Related Art 

Mobile IP is a protocol which allows laptop computers or other mobile computer 
units (referred to as '^Mobile Nodes" herein) to roam betw^n various sub-networks at 
various locations — while maintaining internet and/or WAN connectivity. Without 
Mobile IP or related protocol, a Mobile Node would be imable to stay connected while 

15 roaming through various sub-networks. This is because the IP address required for any 
node to communicate over the internet is location specific. Each IP address has a field 
that specifies the particular sub-network on which the node resides. If a user desires to 
take a computer which is normally attached to one node and roam with it so that it passes 
through different sub-networks, it cannot use its home base IP address. As a result, a 

20 business person traveling across the country cannot merely roam with his or het computer 
across geographically disparate network segments or wireless nodes while remaining 
coimected over the internet. This is not an acceptable state-of-af&irs in the age of 
portable computational devices. 

To address this problem, the Mobile IP protocol has been developed and 

25 implemented. An implementation of Mobile IP is described in RFC 3344 of the Network 
Working Groiq), C. Perkins, Ed., *TP Mobility Support for IPv4," August 2002. Mobile 
IP is also described m flie text **Mobile IP Unplugged" by J. Solomon, Prentice Hall. 
Both of these references are incorporated herein by reference in their entireties and for aU 
purposes. 

30 The Mobile IP process and environment are illustrated in FIG. 1 . As shown there, 

a Mobile IP environment 2 includes the internet (or a WAN) 4 over which a Mobile Node 
6 can communicate remotely via mediation by a Home Agent 8 and a Foreign Agent 10. 
Typically, the Home Agent and Foreign Agent are routers or other network connection 
devices performing appropriate Mobile IP functions as implemented by software, 

1 
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•s 

hardware, and/or firmware. A particular Mobile Node (e.g., a l^top computer) plugged 
into its home network segment connects with the internet Whoi the Mobile Node roams, 
it communicates via the internet through an available Foreign Agent Presumably, there 
are many Foreign Agents available at geographically disparate locations to allow wide 
5 spread internet connection via the Mobile IP protocol. Note that it is also possible for the 
Mobile Node to register directly with its Home Agent. 

As shown in FIG. 1, Mobile Node 6 normally resides on (or is 'T)ased af a 
network segment 12 which allows its network entities to communicate over the intemet 4. 
Note that Home Agent 8 need not directly coimect to the. intemet For example, as shown 

10 in FIG. 1, it may be connected through another router (a router Rl in this case). Router 
Rl may, in tum, coimect one or more other routers (e.g., a router R3) with the intemet 

Now, suppose that Mobile Node 6 is removed from its home base network 
segment 12 and roams to a remote network segmmt 14. Network segment 14 may 
include various other nodes such as a PC 16. The nodes on network segment 14 

1 5 coBDonunicate with the intemet througih a router which doubles as Foreign Ag^ 1 0. 
Mobile Node 6 may identify Foreign Agent 10 tiirough various solicitations and 
advertis^ents which form part of flie Mobile IP protocol When Mobile Node 6 engages 
, with network segment 14, Foreign Agent 10 relays a registration request to Home Agent 
8 (as indicated by the dotted line '"Registration"). The Home and Foreign Agents may 

20 then negotiate the conditions of the Mobile Node's attachment to Foreign Agent 10. For 
exanqple, the attachment may be hmited to a period of time, such as two hours. When &e 
negotiation is successfully coinpleted. Home Agent 8 i^dates an internal 'Mobility 
binding table" which spedfies the care-of address (e.g., a collocated care-of address or 
the Foreign Agent's IP address) m association with the identity of Mobile Node 6. 

25 Further, the Foreign Agent 1 0 updates an internal *^dsitor table" which specifies tiie 

Mobile Node address. Home Agent address, etc. In effect, the Mobile Node's home base 
IP address (associated with segment 12) has been shifted to the Foreign Agent's IP 
address (associated with segment 14). 

Now, suppose that Mobile Node 6 wishes to send a message to a correspondiug 

30 node 18 from its new location. An output message from the Mobile Node is then 
packetized and forwarded through Foreign Agent 10 over the intemet 4 and to 
corresponding node 18 (as indicated by the dotted line "packet from MN") according to a 
standard intemet protocoL If corresponding node 18 wishes to send a message to Mobile 
Node - whether in reply to a message from the Mobile Node or for any other reason - it 
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addresses that message to the IP address of Mobile Node 6 on sub-netwoik 12. The 
packets of that message are then forwarded over tiie internet 4 and to router Rl and 
ultimately to Home Agent 8 as indicated by the dotted line ('jacket to MN(1)'0- Fiom its 
mobility binding table, Home Agent 8 recognizes that Mobile Node 6 is no longer 
S attached to network segment 12. It then enc^sulates the packets fix>mcorreqKmding 
node 18 (which are addressed to Mobile Node 6 on network segment 12) according to a 
Mobile IP protocol and forwards these encapsulated packets to a "care of address for 
Mobile Node 6 as shown by the dotted line C*packet to MN(2)"). The care-of address 
may be, for example, the IP address of Foreign Agent 10. Foreign Agent 10 then strips 

10 the encapsulation and forwards the message to Mobile Node 6 on sub-network 14. The 
packet forwarding mechanism implemented by the Home and Foreign Agents is often 
referred to as *iunneling.'' 

During registration of a mobile node with its Home Agent, the identities of the 
sending party of the registration request (e.g., mobile node) and the sending party of the 

15 registration reply (e.g.. Home Agent) are authenticated. During the registration process, a 
Mobile-Home Authentication Extension is typically appcadeid to both the registration 
request and the registration reply, l^on receipt of the registration request by the Home 
Agent and the registration reply by tiie mobile node, the identity of the sending party is 
authenticated through the plication of the Mobile-Home Authentication ExtensioiL 

20 RFC 3344 specifies the packet format for both the registration request and the 

registration reply packets that are sent between the mobile node and the Home Agent 
As shown in FIG. 2, a registration request packet 202 and registration reply packet 
204 both include a mandatory Mobile-Home Authentication ^ctension (MHAE) 206. 
More specifically, the mandatory Mobile-Home Autiientication Extension 206 

25 includes a type field 208, a lengtii field 210, a security parameter index (SPI) field 
212, and an authenticator 214. The type field 208 mdicates the type of the extension 
(i.e., Mobile-Home Autiientication Extension) and the length field 210 indicates the 
length of the extension (e.g., bytes). The Security Parameter hidex 212 is an identifier 
which specifies a security association, or '*rQw" in a security-association table, that a 

30 receiver should use to mterpret a received packet. The security-association, described 
in fiirther detail below, defines the key and the algorithm to be ^lied during the 
authentication process. Both the registration request packet 202 and the registration 
reply packet 204 include a protected area 216 which includes the registration request 
202 / registration reply 204, the type field 208, tiie length field 210, and flie security 

3 



wo 2004/049672 PCT/US2003/036850 

" parameterindex(SPr) field 212. Both the MobUe Node and the Home Agent are 
typically configured with the same secret key, provided by the security-association, 
which is used to hash this protected area 216 to create the authenticator 214. 

FIG. 3 is a process flow diagram illustrating the process steps performed 
5 during authentication of a Mobile Node. As shown, the process begins at step 302 
and at stqp 304, the Mobile Node constructs a registration request including a 
protected area. At step 306, the Mobile Node generates an auttienticator by hashing 
the protected area with the key through application of a specified algorithm. The 
mobile node then sends the registration request which includes the protected area and 

10 the auttienticator to the Home Agent at step 308. The Home Agent then identifies all 
necessary information such as the key and the algorithm used to generate its 
authenticator fix)m a security-association, corresponding to the SPI of the registration 
request, at step 310. Next, at step 312, the Home Agent generates its authenticator by 
hashing the protected area of the registration request with the key using the algorithni 

1 5 identified by the SPI. The Home Agoit then compares the authenticator generated by 
the mobile node with the authenticator generated by the Home Agent. If it is 
determined at step 314 that the authenticators match, the mobile node is authenticated 
at step 316 and the process is conqileted at step 318. However, if the authenticators 
do not match, the Mobile Node is not authenticated at step 320 and the process is 

20 completed at step 322. Authentication may similarly be perfoimed by the Mobile 
Node iq>on receipt of the registration rq)ly that is sent by the Home Agent However, 
a different SPI and therefore security-association may be applied during 
autiientication of tiie Home Agent. 

As described with respect to the authentication process, a Security Association 

25 provides information that is used to generate the authenticators during the 

authentication process. FIG. 4 is a diagram illustrating a conventional security 
association table that is typically configured on each Home Agent. As shown, a 
security association table 402 typically includes at least one entry 404 for each mobile 
node supported by that Home Agent. By way of example, multiple security 

30 associations may be applicable to different types of data transfers which have 

diiBferent security requirements. Each entry 404 may include a mobile node identifier 
406 for the mobile node such as the IP address of the mobile node and an SPI 408 
identifying the security association within the security-association table. In addition, 
an autiientication key 410 (e.g., a secret key) tiiat is shared between the Mobile Node 

4 
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and the Home Agent is provided (e.g., keyed MDS). An algoritiim 412 used to create 
the aulhenticator is provided (e.g., RSA Message Digest Algorithm MDS). Moreover, 
a mode 414 such as prefix, su£Bx, or prefix-suffix indicates the mode used during 
authentication. This mode indicates tiie portions offhe protected region that ate 
S hashed with the key. In addition, each entry 4Mfi]rther includes a replay timer 416, 
or timestamp, that mdicates a maximum time during which the registration request 
may be replayed. The replay timer protects against unautiiorized copying and 
'^laying^' of registration requests for the purpose of defeating authentication. 
Even though the replay timer can reduce the risk of replaying a registration 

10 request, there exists a risk of compromising statically configured keys. Specifically, 
when a shared key is statically configured at the Home Agent and the Mobile Node, 
the shared key is rq)eatedly re-used. As a result, there is a possibility that a statically 
configured key may be discovered over numerous communications. The encrypted 
information that may be decrypted via this shared key is therefore also compromised. 

1 5 Security-association tables may potentially include many thousands of entries 

and therefore consume a substantial amount of memory. As described above, at least 
one entry is typically provided in such security-association tables for each Mobile 
Node siq;>ported by the corresfponding Home Agent Moreover, these security- 
association tables are typically stored in non-volatile mraaory to prevent destruction 

20 of this information. This does not pose a problem when the Home Agent is a 
workstation having very large hard disks or other forms of non-volatile memory. 
However, when a network device such as a router or switch serves as the Home 
Agent, memory, particularly non-volatile memory, is a premium resource. Although 
the use of non-volatile m^ory ensures that security-associations will not be 

25 irretrievably lost, non-volatile RAM in a typical router is limited. By way of 
example, the non-volatile RAM may be approximately 128 kilobytes in a typical 
router. Since each security association consumes ^proximately 80 bytes of memory, 
the number of security associations that may be stored on a Home Agent is limited to 
about 1500. Actually, a portion of the router's NVRAM must be set aside for other 

30 puiposes, so the actual number of security associations that it can store will be 

significantiy less than the theoretical maximum. In short, the physical hmitation in 
memory makes it impossible to store the security-associations for all mobile nodes 
that could otherwise be supported by a Home Agent 



5 
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In addition, tiie security-association tables are typically manually configured 
for each Home Agent FIG. S is a block diagram illustrating a mobile IP network 
segment and associated environment. Mobile JP environment 502 includes the 
intemet (or a WAN) 504 over which various mobile nodes can communicate remotely 
5 via mediation by a corresponding Home Agent (via an appropriately configured router 
denoted Rl). An entity such as a corporation, business, or government may provide 
multiple Home Agents. Here, a first Home Agent 506, a second Home Agent 508, a 
third Home Agent 510, a fourth Home Agent 512, and a fifth Home Agent 514 are 
shown. As shown, such an environment lacks a centralized source of security 

10 associations. Therefore, each Home Agent must be separately configured for Mobile 
Nodes supported by that Home Agent. Moreover, redundant Home Agents may be 
provided to permit a Home Agent to serve as a backup to protect against failure by a 
primary Home Agent By way of example, the fourth Home Agent 512 and the fifHi 
Home Agent 514 may store identical security-associations in the event that one of the 

15 Home Agents fails. Thus, when a security-association is updated (e.g., a key is 
modified) the security-association must be updated on all of the redundant Home 
Agents. Accordingly, such a system requires considerable administrative overhead. 

In view of the above, it would be desirable if a centralized source of shared 
keys could be implemented. Moreover, it would be beneficial if the risk of 

20 discovering shared keys could be reduced or elimiiiated. 

SUMMARY OF THE INVENTION 

Metiiods and apparatus for providing a centralized source of session keys to be 
shared by a Home Agent and a Mobile Node are disclosed. This is accomplished, in 
25 part, through the use of a AAA server used to provide relevant key information to the 
Home Agent. In this manner, the Mobile Node and its Home Agent may separately 
derive the shared key, eUminating the need to transmit the shared key and the risk of 
its decryption. 

In accordance with one aspect of the invention, a Mobile Node registers with a 
30 Home Agent supporting Mobile IP by sending a registration request to the Home 
Agent. When the Mobile Node receives a registration reply from flie Home Agent, 
the registration reply indicates that the Mobile Node is to derive a key to be shared 
between the Mobile Node and the Home Agent. The Mobile Node then derives a key 
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to be shared between the Mobile Node aad the Home Agent from key infonnation 
stored at the Mobile Node. 

In accordance with another aspect of the invention, a server adapted for 
authentication, authorization, and accounting (AAA) receives a request message (e.g., 
5 access-request message) from a Home Agent, the request message identifymg the 
Mobile Node. The AAA server then derives key information fiom a key or password 
associated with the Mobile Node. The key or password may obtained from another 
server, such as a Microsoft Windows™ domain controller. The AAA server then 
sends a reply message to the Home Agent, the reply message including the key 

10 infonnation associated with the Mobile Node, thereby enabling the Home Agent to 
derive a shared key to be shared between the Mobile Node and the Home Agent from 
the key information. 

In accordance yet another aspect of the invention, a Home Agent receives a 
registration request fiom a Mobile Node, the registration request identi^dng the 

1 S Mobile Node. The Home Agent sends a request message (e.g., access-request 

message) to a AAA server, the request message identifying the Mobile Node. The 
Home Agent receives a reply message (e.g., access-reply message) fi^om the AAA 
server, the reply message including key information associated with the Mobile Node. 
The Home Agent derives a key 6om the key information, the key bdng a shared key 

20 between the Mobile Node and the Home Agent A registration reply is then sent to 
the Mobile Node. 

In accordance with yet another aspect of the invention, the Mobile Node may 
initiate re-keying by sending a subsequent registration request to the Home Agent 
The Home Agent and the Mobile Node may then derive a key from tiie previously 
25 used session key. Keys can be generated each tune a bmding is cleared, such as upon 
expiration of tiie MobUe Node's Ufetime or de-registration of the Mobile Node. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagram illustrating a Mobile IP network segment and associated 
30 environment 

FIG. 2 is a diagram illustrating conventional Registration Request and 
Registration Reply packet formats having a Mobile-Home Authentication Extension. 

FIG. 3 is a process flow diagram illustrating the process steps performed 
during authentication of a mobile node. 

7 
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FIG. 4 is a diagram illustratiBg a conventional Security Association. 

FIG. 5 is a block diagram illustrating a mobile IP network segment and 
associated enviromnent without a centralized source of security keys. 

FIG. 6 is a block diagram illustrating an exenq)laiy system in which the 
S preset invention may be unpl^ented. 

HG. 7 is a transaction flow diagram illustrating a general method of 
performing dynamic key generation in accordance with various embodiments of the 
invention. 

FIG. 8 is a transaction flow diagram illustrating a specific method of 
10 performing dynamic key generation in accordance with various embodiments of the 
invention. 

FIG. 9 is a process flow diagram illustrating a method of composing a 
registration request as illustrated at block 812 of PIG. 8. 

FIG. lOA is a diagram illustrating an exemplary registration request message 
1 5 that may be transmitted by a Mobile Node in accordance with various embodiments 
of the invention. 

FIG. lOB is a diagram illustrating an exemplary registration reply message 
that may be transmitted by a Home Agent to a Mobile Node in accordance with 
various embodiments of the invention. 
20 FIG. 1 1 A is a diagram illustrating an exeiiq)lary registration reply message 

that may be subsequently transmitted by a Mobile Node in accordance with various 
embodiments of the invention. 

FIG. IIB is a diagram illustrating an exemplary registration reply message 
that may be sufosequentiy transmitted by a Home Agent to a Mobile Node to initiate a 
25 subsequent rekeying in accordance with various embodiments of the inventioit 

FIG. 12 is a block diagram of a network device that may be configured to 
implement aspects of the present invention. 

DETAILED DESCRIFnON OF THE INVENTION 

30 In the following description, numerous specific details are set forth in order to 

provide a thorough understanding of the present invention. It will be obvious, 
however, to one skilled ia the art, that the preset invention may be practiced without 
some or all of these specific details. In other instances, well known process steps 
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have not been described in detail in order not to unnecessarily obscure the present 
inventioa 

FIG. 6 is a block diagram illustratmg an exonplary system in which the 
present invention may be inq)lemented. When a Mobile Node 602 does not share a 
5 security association witti its Home Agent 604, both the Mobile Node 602 and the 
Home Agent 604 may separately dynamically generate a shared key. In this manner, 
their identities may be authenticated during the registration process. 

As shown m FIG. 6, registration may be fiidlitated by a Foreign Agent 606, or 
be performed without a Foreign Agent 606. In other words, the Mobile Node 602 
10 may register via a collocated care-of address. In order to simplify tiie following 

description, it is assumed that the Mobile Node 602 registers via a collocated care-of 
address. 

In order to separately generate a shared key, the Mobile Node is configured 
with key information such as a key **root ke/* or password such as a Wiudows™ 

15 password. From this key infonnation, the Mobile Node may derive the shared key. 
The Mobile Node preferably derives the shared key in response to a registration reply 
received team the Home Agent. For instance, the registration reply may indicate that 
the shared key is to be derived by the Mobile Node. 

Mobility keys may be stored on an authentication, authorization, and 

20 accounting (AAA) server that can be accessed using TACACS+ or RADIUS 

protocols. While authentication determines who an entity is, authorization determines 
what services a user is allowed to perform, or access. Various protocols such as the 
Remote Authentication Dial In User Service (RADIUS) and TACACS+ may be 
inq>lemented to provide such a server. In addition, this protocol may similarly be 

25 implemented on each Home Agent that communicates with the server. RFC 2138 
describes the RADIUS Protocol and is hereby incoiporated by reference. Similarly, 
RFC 1492 describes TACACS and the hitemet-Draft **The TACACS+ Protocol 
Version 1.78," available athttp:/Avww.ietf.org/intemet-drafts/drafl-grant-tacacs- 
02,txt, describes TACACS+. Botii of these documents are incorporated herein by 

30 reference for all purposes. 

The Home Agent obtains its set of key information from a AAA server 608. 
As described above, the AAA server 608 may store shared keys or security 
assocations. However, in accordance with various embodiments of the invention, the 
AAA server stores key information from which a shared key may be derived rather 



wo 2004/049672 



PCT/US2003/036850 



than ttie shared keys or security associations. As described above, the key 
infonnation may include a '^ot key" or password such as a Windows™ password. 
Alternatively, a secondary device 610 and/or storage medium may be accessed by the 
AAA server 608 to retrieve the key information. Since the shared key is not 
5 transmitted, the shared key caimot be easily discerned fiom a listener to the 
transmissions. 

In addition to not transmitting the shared key, it is preferable if the initial key 
information is not transmitted as well. Thus, the AAA server 608 preferably derives 
intermediate key material to be transmitted to the Home Agent 604. The Home Agent 

1 0 may then derive the shared key from this intermediate key material. 

Jn accordance with one embodiment, the secondary device 610 is a domain 
controller operating under the Lightweigjit Directory Access Protocol (LDAP). The 
domain controller operates using MS-Chap version 2 (MS-Chapv2). In order to 
authenticate the Mobile Node, the Home Agent sends a request to the AAA server 

15 608 on behalf of the Mobile Node. The protocol that the Home Agent 604 specifies 
to authenticate the Mobile Node is MS-CHAPv2. The AAA server 608 may then 
retrieve die key information fix)m the secondary device 610 for purposes of deriving 
die intermediate key material for transmission to the Home Agent 604. 

The methods desoibed herem are impl^ented using MS-Ch£q)v2 to achieve 

20 dynamic key generation between the Mobile Node and Home Agent MS-Chapv2 
provides for bi-4irectional authentication between a client (Mobile Node) and 
Network Access Server (Home Agent). However, although the methods disclosed 
herein are described with reference to the MS-CHAPv2 protocol, key generation for 
Mobile IP may be performed using a variety of protocols. 

25 Once the Home Agent and Mobile Node have separately dynamically 

generated tiie shared key, the shared key may be used to derive subsequent keys to be 
used in transmissions between the Home Agent and the Mobile Node. For instance, 
the derivation of subsequent keys may be triggered by de-registration of the Mobile 
Node or expiration of the lifetime of the Mobile Node. The generation of subsequent 

30 keys may therefore hinder the ability of an outsider to discover a shared key and 
decrypt encrypted messages. 

In the following description, a general method of performing dynamic key 
generation is described below with reference to FIG. 7, while a more specific method 
of performing dynamic key generation is described below with reference to FIG. 8. 

10 
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FIG. 7 is a transaction flow diagram illustrating a general method of p^oiming 
dynaxnic key generation in accordance with various embodiments of the invention. 
Steps perfoimed by the Mobile Node, Home Agent, AAA server, and Domain 
Controller are represented by vertical lines 702, 704, 706, and 708, respectively. As 
5 described above, key information x such as a root key or password is installed at the 
Mobile Node at 710. In addition, the key information x is installed at the AAA server 
or Domain Controller at 711. 

The Mobile Node composes a registration request at 712, which is sent to the 
Home Agent at 714. The registration request packet may indicate that special 

10 processing is required by the Home Agent in order to dynamically generate a shared 
key. An exemplary registration request packet will be described in firrther detail 
below with reference to FIG. lOA. Jn order to obtain the Mobile Node's key 
information, the Home Agent sends a request message at 716 to the AAA server. For 
instance, the request message may be a RADIUS access request message. 

IS Alternatively, the request message may be transmitted via the TACACS+ protocol. 

When the AAA server receives the request message, it may obtain the key 
information x fiom the Domain Controller if it does not store the key information x 
locally. Thus, the AAA server sends a request for tiie key information x associated 
with the Mobile Node at 71 8 to the Domain Controller. The Domain Controller then 

20 sends tiie key information x to tiie AAA server at 720. 

Once the key information x is obtained or received by the AAA server, the 
AAA server may derive key material x' or x" to be transmitted to the Home Agent 
In other words, while it is possible to transmit the key information x to the Home 
Agent, there is a risk that the key information x may be decrypted by a hstener of the 

25 communications. If the key information x were discovered, the shared key could also 
be generated. Thus, ratiio: than transmitting the key information x, it is preferable to 
generate key material x' or x". In accordance with one embodiment, the AAA server 
derives x' at 722 to authenticate the access request message previously received at 
716. The AAA server then derives key material x' * to be transmitted to the Home 

30 Agent 704. Specifically, the AAA server sends a reply message such as a RADIUS or 
TACACS+ access reply message including the key material x*' at 724 to the Home 
Agent 

The Home Agent generates a shared session key as shown at 725. Once the 
session key, Skey, is generated, the key material x" used to generate the session key 

11 
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' may be discarded by flie Home Agent at 726. The Home Agent then sends a 
registration reply at 727 to the Mobile Node, after derivation of the shared key by the 
Home Ag&A. Specifically, if the access reply message indicates that authentication of 
the Mobile Node is not successful, the Home Agent does not send a registration reply. 
S However, if the access rq)ly message indicates that authentication of the Mobile Node 
is successful, the Home Agent sends a registration reply to the Mobile Node. An 
exenq)lary registration reply will be described in further detail below witih reference to 

naiiA. 

When the Mobile Node receives the registration rqply, it derives a shared 
10 session key from its key information (e.g., root key or password). For instance, the 
registration reply may indicate that the Mobile Node is to dynamically generate the 
shared session key. In this example, the Mobile Node derives key material x* and x'* 
using a one-way hashing fimction at 728. . At this point, the Mobile Node and the 
Home Agent are in possession of the same key material x'' as shown at 730. From 
IS this key material, the Mobile Node may indq>end6ntiy generate a shared session key 
as shown at 732. 

A variety of formulas may be used to generate the shared session key (at the 
Home Agent and flie Mobile Node). The only requirement is that flie Mobile Node 
and the Home Agent generate tiie shared session key via the same formula. In tiiis 
20 exanq)le, the shared session key, Skey, is derived firom the following fomiula: 
(1) Skey = hash (key material x" + random number) 
The **hash" fimction can be any secure one-way hash function, such as MD5 or 
HMAC-MD5. Once tiie session key, Skey, is generated, the key material x" used to 
generate the session key may be discarded by the Mobile Node at 734. 

As will be described in fiirdier detail below with reference to FIG. 8, a 
subsequent d^ved session key, Skey*, may be derived from master Skey. The use of 
the derived Skey' may minimize the number of messages auflienticated using the 
master Skey to maintain the secrecy of the master Skey. This derived session key, 
Skey', may then be periodically '^refreshed." Specifically, at 736 the Mobile Node 
may send a subsequent registration request to the Home Agent in order to ^Vefresh" 
the shared session key, Skey'. An exemplary subsequent registration request will be 
described in further detail below with reference to FIG. lOB. Since the Mobile Node 
and the Home Agent now share a session key (Skey), the Home Agent is able to 
authenticate the Mobile Node without contacting the AAA server. As described 

12 
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above, Skey is generated using x". Once the lifetime expires, the Home Agent and 
Mobile Node preferably discard all dynamic keys (e,g., Skey and Skey*) and thus the 
Mobile Node sends a registration request as shown in FIG. lOA to reinitiate the key 
generation. Typically, the Mobile Node sends a registration request before the li&time 
5 expires. Skey' can therefore be derived while the Skey still exists and such messages 
are authenticated using Sk^, as shown in FIG. lOB and FIG. IIB. 

A subsequent registration reply is then sent by the Home Agent at 737 to the 
Mobile Node, either before or after generation of the shared key by the Home Agent. 
The registration reply is authenticated using Skey, and therefore it is irrelevant 

1 0 whether Skey* has been derived prior to sending the subsequent registration reply. 
The subsequent registration reply preferably indicates to tihie Mobile Node that it is to 
generate a new session key, as set forth above. An exemplary subsequent registration 
reply will be described in further detail below with reference to FIG. 1 IB. 

It may be desirable to generate a new session key upon successful re- 

15 registration of the Mobile Node. Thxis, the Home Agent and the Mobile Node 

independently generate a derived session key at 738 fix>m the previously used session 
key. In this example, the derived session key, Skey', is derived fiom the following 
formula: . 

(2) Skey' = hash (Skey + random number) 

20 Once the Home Agent and the Mobile Node have independently derived flie 

new session key, Skey*, the previous session Skey' (if existing) may be discarded by 
the Home Agent and Mobile Node as shown at 740 and FIG. lOA. However, Skey 
remains the same and is not discarded. The Skey may therefore be subsequently used 
for purposes of generating a new Skey' by sending a registration request as shown in 

25 FIG. 1 OB. The Skey remains unmodified until he MN reinitiates authentication at 712 
and shown in FIG. lOA. Keys may also be discarded each time the Mobile Node de- 
registers with the Home Agent, requiring key generation upon subsequent re- 
registration with the same or a different Home Agent as shown at 742 in accordance 
with the above-described process based Mpon the previous session key. 

30 FIG. 8 is a transaction flow diagram illustrating a specific method of 

performing dynamic key generation in accordance with various embodiments of the 
invention. Steps performed by a Mobile Node, Home Agent, AAA server, and 
Domain Controller operating under LDAP rqiresented by vertical lines 802, 804, 806, 
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and 808, respectively. A Windows™ password is installed at the Mobile Node at 810 
as well as at the Domain Controller at 811. 

Typically, the NAS server sends a NAS-^hallenge to the client The client 
generates a peer-challenge and a challenge response based on the following: the 
5 usemame (which can be derived from the Network Access Identifier (NAT) by 

stripping oS realm and "@)", the NAS-Challenge, peer-challenge, and MD5 hash of 
the hashed password k. In the Windows™ environment, the usemame for response 
calculation is of the form: domainXusemame. RFC-2759, 'Microsoft PPP CHAP 
Extensions, Version 2," G. Zom, January 2000 discloses the format of PPP CHAP 
extensions as implemented in the Microsoft Windows™ environment, and is 
incorporated herein by reference for all purposes. Since in temis of Mobile IP, the 
Mobile Node does not send an indication to the Home Agent that it wants to register 
until a registration request is sent (which has to be authenticated), the Home Agent 
does not know of the Mobile Node's presence or intention and thus cannot send a 
NAS-Challenge. Thus, the solution is for the Mobile Node to generate a NAS 
challenge and embed it in the registration request message. The usemame is 
implicitly carried in the NAI extension. The domain name information (if available 
and used for response calculation) is carried in a separate extension. The peer 
challenge is calculated by calculating hash (MDS) of the registration request, after 
zero-filling the diallenge response extension value. The challenge response is filled 
for the Home Agent/AAA/backend database to authenticate the registration request 
The domain name, peer-challenge, authentication protocol and SPI information for 
keys are carried in Mobile TP extensions. These are of the form TLV 
(type/lengfh/value) and are derived as specified in RFC -3115, "Mobile IP 
Vendor/Qrganization-Specific Extensions," Dommety et al, April 2001, which is 
incorporated herein by xefcKmce for all purposes. 

In order to initiate a Mobile IP session, tibie Mobile Node composes a 
registration request at 812 and sends it to the Home Agent at 8 14. A method of 
composing a registration request will be described in further detail below with 
reference to FIG. 9, Specifically, in order to enable the Mobile Node to be 
authenticated, the Mobile Node provides CHAP mformation in flie registration 
request, such as the CHAP challenge and response. An exemplary registration request 
will be described in fiuiber detail below with reference to FIG. lOA. 
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When the Home Agent receives the registration request packet at 816, the 
Home Agent determines whether special processing of the registration request is 
required. For instance, this may he detemiined fiom the presence or absence of one 
or more exlsisions and/or a specific SPI in the registration request (e.g., the Mobile- 
5 Home Authentication Ext^ion(MHAB)). In this manner, the Home Agent may 
ascertain that the Home Agent is to derive a shared key between the Mobile Node and 
the Home Agent For mstance, the shared key may be derived from key information 
obtained from a AAA server. 

Ih order to keep track of pending registration requests and key information that 

10 has been received fix>m a AAA server, the Home Agent stores state information 
associated with the registration request at 8 1 7. For instance, the state information 
may include iirfomiation provided in the registration request The Home Agent may 
then send a request message such as a RADIUS or TACACS+ access-request 
identifying the Mobile Node at 818 to a AAA server. The access-request preferably 

15 includes CHAP information in a vendor specific attribute (VSA). The CHAP 
information may include the CHAP challenge and response. 

As described above, a password or key, k, is configured at the Mobile Node as 
well as the AAA server (or at a domain controller). For instance, fiie password or key 
may comprise a Windows™ password associated with the Mobile Node. 

20 In the presmce of a domain controller, the AAA server sends the usemame, 

domain name and chap challmge and response in an access request message at 820 to 
the domain controller for authentication of the Mobile Node. If authentication is 
successfiil, tiie AAA server receives the key material k' ' and a success code as an 
access reply as shown at 822 and 824. tnthismanner, the AAA serv^ returns the key 

25 material k" to the Home Agent 

In the absence of a domain controller, the AAA server is aware of k (and thus 
k'). Specifically, the AAA server either receives the key or password at 822 firom the 
domain controller 6om which it may derive the key information k* and generate the 
key mat^al k" at 824, or the AAA server locally authenticates the chap request and 

30 if successfid, returns k' ' to the HA in an access-accept message. 

As described above, challenge response is filled for the Home Agent, AAA 
server, or backend database to authenticate the registration request. If authentication 
by the AAA server or backend database is successfiil, the Home Agent has indirectiy 
authenticated the registration request 

15 
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If the aufhentication is successful, the AAA or domam contFoller may then 
derive key material k" &om the key infomatadon. The AAA server then sends arq>ly 
message (e.g., access-accq)t message or access-reject message) at 826 to the Home 
Agent including the key material k*' (upon successful authentication) associated with 
5 the Mobile Node, thereby enabling the Home Agent to derive a shared key to be 
shared between the Home Agent and the Mobile Node. The access-accept message 
includes a VSA for the key material (k' For instance, fihe VSA may be a Microsoft 
Pomt-to-Pomt Encryption AAA attribute in accordance with RFC 2548, ^'Microsoft 
Vendor-specific RADIUS Attributes," G. Zom, March 1999, which is incorporated 

10 herein by reference for all purposes. 

Upon receipt of the reply message (e.g., access-accept message) by the Home 
Agent indicating that the Mobile Node has been authenticated, the Home Agent 
creates a binding in a mobility binding table between the Mobile node and the care-of 
address specified in the registration request at 827. The Home Agent may then derive 

15 the shared key iiom the key material k". In accordance with one embodmient, in 
order to derive the shared key, the Home Agent obtains the CHAP challenge and 
response from die registration request at 828. The Home Agent then generates the 
shared session key using the CHAP challenge and response and the key material k" at 
830. Specifically, the Home Agent p^orms an MDS hasliiTig function on the key 

20 material k", the CHAP challenge and response. In order to store a security 
association and enable the Mobile Node to generate ajcorresponding security 
association, the Home Agsaat obtains Skey and Skey' extensions fix)m the registration 
request in order to append these extensions to a registration reply at 832. For 
instance, the Skey and Sk^r' extensions may specify the SPI and other related 

25 informatiorL These extensions wiU be described in fiulher detail below with reference 
to FIG. lOA and FIG. lOB. The Home Agent then installs the shared key, Skey, and 
associated Skey information from the Skey extension in a security association table at 
834. In addition, the Home Agent preferably installs the derived shared key, Skey% 
and associated Skey' information Scorn the Skey* extension in the security association. 

30 This enables the Skey' to be used for authenticating subsequent registration requests, 
which minimizes Skey usage and possibility of compromise of the Skey. Specifically, 
the Home Agent mstalls the key/derived key, the SPI, the replay protection 
timestamp, and the encryption algorithm m a security association. The MHAE is then 
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calculated using the shared session key (Skey). The key material k" may then be 
discarded at 838. 

The registration vcply having the Skey and Skey* extensions is then composed 
at 840 is then sent at 842 to the Mobile Node. Note that these extension aie identical 
S to those that were received in the registration request. Specifically, the Home Agent 
may have selected a different SPI for each extension to set up a unidirectional 
Security Association. The actual keys, Skey and Skey', are not sent in these 
extensions. The Home Agent may also provide information in an extension to the 
registration reply that enables the MN to authmticate the HA (if bidirectional 

1 0 authentication is desired). An exemplary registration reply will be described in 
further detail below with reference to FIG. lOB. 

In response to its registration request, the Mobile Node receives a registration 
reply fix)m the Home Agent at 844. The Mobile Node may then determine &om the 
registration reply whether special processiag is to be performed by the Mobile Node. 

IS In other words, the registration reply may indicate that the Mobile Node is to derive a 
key to be shared between the Mobile Node and the Home Agent. For instance, the 
Mobile Node may ascertain fix>m the presence of one or more extensions to the 
registration reply and/or a particular SPI in the registration reply (e.g., MEEAE) may 
indicate that the Mobile Node is to derive the shared key between the mobile Node 

20 and the Home AgCTt 

As described above at 8 10, key information k is stored at the Mobile Node. 
The key information may be, for example, a root key, or a password such as a 
Windows™ password. From this key ioformation, the Mobile Node may d^ve the 
shared session key. In addition, a subsequent session key may be derived &om a 

25 previous session key, as will be described in further detail below with reference to 
steps 856-864. 

In order to derive the shared session key, the MN derives k' and k' ' at 846 
using a one-way hashing function, as described above. In addition, the MN obtains 
the CHAP challenge and response from the registration reply at 848. Specifically, the 
30 MN can correlate the registration request previously sent with the registration reply 
based upon an ID field in the registration request and reply. The Mobile Node then 
generates the shared session key from the key information k, as described above with 
reference to the Home Agent, and discards at 850. The Mobile Node then 
authenticates the registration reply using the shared key and compares the result with 
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the aufhenticator in MHAE at 852. Once the Mobile Node has authenticated the 
registration reply, it installs both the session key, Skey, and the derived session key, 
Skey', with the infomxadon obtained from the Skey and Skey' information obtained 
jGrom the Skey and Skey' extensions, respectively, in die security association at 854. 
5 Specifically, the Mobile Node installs the key/derived key, the SPI» tiie rq>lay 
protection timestamp, and the algorithm in a security association. 

Once the masto: Skey and derived Skey*are installed, a subsequent registration 
request can be sent to refiresh/renegotiate the derived Skey*. Such messages are 
authenticated xising the master Skey. In addition, the registration request contains the 

10 Skey* extension indicating that the Skey' is to be generated. The registration reply in 
such cases is authenticated using the master Skey and contains the Skey' extension to 
indicate that the Skey' is to be generated. 

In order to refresh the shared key for use in subsequent transmissions betweea 
the Mobile Node and Home Agent, it may be desirable to derive a subsequent session 

1 5 key &om the shared session key previously derived. In other words, since the shared 
session key is already in use for a period of time or a number of transmissions, there is 
a risk that a listener may intercept these communications and determine the session 
key that is used. Thus, it may be desirable to periodically generate a new session key 
fiom the session key previously used (e.g., after a specified period of time or number 

20 of transmissions). 

In order to refiresh the session key, a subsequent registration request is sent by 
the obile Node to the Home Agent at 856. An exernplary subsequent registration 
request will be described in further detail below with reference to FIG. 1 1 A. The 
Home Agent and Mobile Node indq)endently generate a derived session key, Skey', 

25 at 858. For instance, the dmved session key Skey' is generated by using an MDS 

hashing fimction of the Sk^ and a random number (e.g., timestamp obtained fiom the 
registration request). Thus, in order to refiesh the derived session key, Skey', the 
Skey is used. In addition, the initial, imchanging Skey is xised for purposes of 
authenticating this subsequent registration request The previous derived session key, 

30 Skey', can then be discarded at 860. Subsequent session keys can be geuCTated each 
time a binding is cleared (e.g., upon expiration of the Ufetime of the Mobile Node or 
de-registration of the Mobile Node) at 862 as described above. A subsequent 
registration reply is sent by the Home Agent to the Mobile Node at 864. An 
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exemplary subsequent registration reply will be described in fiirilLer detail below with 
reference to FIG. IIB. 

FIG. 9 is a process flow diagram illustrating a method of composing a 
registration request as illustrated at block 812 of FIG. 8. In order to compose a 
S registration request for a Mobile Node that does not have a shared security association 
with its Home Agent, the Mobile Node needs a mechanism for building a MHAE for 
authentication purposes as shown at block 902. Thus, the Mobile Node calculates k' 
and generates a CHAP challenge at block 904. The Mobile Node then generates a 
CHAP response/authenticator using k' at block 906, where the CHAP response is 

10 calculated using at least the identification field, registration request header, and NAI 
fields (if present) at block 908. The Mobile Node then composes a registration 
request at block 910 including the Mobile Node to Home Agent SPI, challenge, and 
authenticator. In addition, the registration request includes a special SPI and/or an 
indicator to indicate to the Home Agent that special processing is required (e.g., to use 

IS MS-CHAP based authentication). 

FIG. lOA is a diagram illustrating an exemplary registration request message 
that may be transmitted by a Mobile Node in accordance with various embodiments 
of tiie invention as shown at 814 of FIG. 8. As shown, the registration request lOQO 
includes a header 1002, Network Access Idmtifier (NAI) extension including a NAI 

20 1004 including the usemame, an S-key extension 1006 including SPIl, replay 
protection timestanq), and identifying the algorithm to be used to authenticate the 
registration request The registration request 1000 also includes a S'-key extension 
1008 including SPI2, replay protection timestan^), and algorithm to be used for 
subsequent re-registrations, as well as to be used to enable the Mobile Node to be 

25 authenticated using the derived session key, Skey', where the Skey' is set up during 
initial registration. Some additional information may be added in registration requests 
and registration replies to facilitate a specific protocol. For example, to use MS- 
Chapv2, the "domain-name" name is transmitted to the Home-Agent in a domain- 
name extension. Thus, the registration request 1000 also includes the CHAP "peer" 

30 challenge 1010 carrying the **peer" challenge, authentication protocol 1012, 

authenticator/challenge response 1014, and MHAE 1016 including the specific SPI. 
Formats for extensions to registration and reply extensions are set forth in RFC 3115, 
^Mobile IP Vendor/Organization-Specific Extensions,** Dommety et al, April 2001, 
which is incorporated by reference for all purposes. In addition, challmge and 
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response extensions are provided as set forth in RFC 3012/ 
Challenge/Response Extensions," Perkins et al, November 2000, which is 
incorporated herein by reference for all purposes. For instance, the presence of the 
authentication protocol extension 1012 in the registration request indicates a protocol 
5 to be used to authenticate Ifae registration request and derive the shared key. An 
example protocol depicted in this ^plication to authenticate the Mobile Node and 
derive the shared key(s) using a AAA infrastructure is MS-CHAPv2. 

FIG. 1 OB is a diagram illustrating an exemplary registration reply message 
that may be subsequentiy transmitted to a Mobile Node in accordance with various 

10 embodiments of the invention as shown at 842. As shown, the registration reply 1017 
includes a registration reply header 1018, NAI 1020, S-key extension 1022 and S'key 
extension 1024 as described above, and MHAE 1026 including special SPI associated 
with the Skey. Specifically, the presence of flie Skey extension in tiie registration 
reply may indicate that the Skey needs to be derived, while the presence of the Skey' 

1 S extension in the registration reply may indicate that the Skey^ needs to be derived or 
refreshed using Skey. 

FIG. 1 1 A is a diagram illustrating an exemplary registration request message 
that may be transmitted by a Mobile Node to initiate subsequent rekeying as shown at 
856 in accordance with various embodiments of the invention. The registration 

20 request 1 100 includes a registration request header 1 102, NAI 1 104, S'-key extension 
1 106, and MHAE 1 108 calculated using Skey. Replay protection is achieved by 
providing a timestanq) 1 1 10 in the registration request. This timestamp is provided 
smce the Home Agent does not validate the challenge 1010, since it did not generate 
the challenge 1010. 

25 FIG. 1 IB is a diagram illustrating an exemplary registration reply message 

tbiat may be subsequentiy transmitted by a Home Agent to a Mobile Node to initiate a 
subsequent rekeying (e.g., of the derived session key, Skey*) as shown at 864 in 
accordance with various embodiments of the invention. The registration reply 1 120 
includes a registration reply header 1 122 including a timestamp, NAI 1 124, S'-key 

30 extension 1 126, MHAE 1 128 calculated using Skey. 
OthCT Embodiments 

Generally, the techniques of the present invention may be implemented on 
software and/or hardware. For ^cample, they can be implemented in an operating 
system kernel, in a separate user process, in a library package bound into network 
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^plications, on a sfpecially constructed machine, or on a network interface card. In a 
specific embodunent of this mvention, the technique of the present invention is 
implemented in software such as an operating system or in an application running on 
an operating system. 

S A software or software hardware hybrid implementation of the techniques of 

this invention may be implemented on a general-purpose programmable machine 
selectively activated or reconfigured by a computer program stored ia memory. Such 
a programmable machine may be a network device designed to handle network 
trafiSc, such as, for example, a router or a switch. Such network devices may have 

10 multiple network intaiaces including firame relay and ISDN interfaces, for example. 
Specific examples of such network devices include routers and switches. For 
example, the Access Points of this invention may be implemented in specially 
configured routers or servers, as well as Cisco Aironet Access Points, available fiom 
Cisco Systems, Inc. of San Jose, Cahfomia. A general architecture for some of these 

IS machines will appear fix)m the description given below. In an alternative 

embodiment, the techniques of this invention may be inq[)lemented on a general- 
purpose network host machine such as a personal computer or woricstation. Further, 
the invention may be at least partially implemented on a card (e.g., an inter&ce card) 
for a network device or a general-purpose computing device. 

20 Referring now to HG. 12, a network device 1560 suitable for inq>lementing 

the techniques of tiie present invention includes a master central processmg unit 
(CPU) 1562, inter&ces 1568, and abus 1567 (e.g., aPCIbus). When acting under the 
control of appropriate software or firmware, the CPU 1562 may be responsible for 
implementing specific fimctions associated with tiie fimctions of a desired network 

25 device. For example, when configured as an intermediate router^ the CPU 1562 may 
be responsible for analyzing packets, enc^sulating packets, and forwarding packets 
for transmission to a set-top box. The CPU 1 562 preferably accompUshes all these 
functions under the control of software including an operating system (e.g. Windows 
NT), and any appropriate applications software. 

30 CPU 1562 may include one or more processors 1563 such as a processor from 

the Motorola family of microprocessors or the MIPS family of miCToprocessors. In an 
alternative embodiment, processor 1563 is specially designed hardware for controlling 
the operations of network device 1560. In a specific embodim^t, a memory 1561 
(such as non-volatile RAM and/or ROM) also forms part of CPU 1562. However, 
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there are many different ways in which memory could be coupled to tiie system. 
Memory block 1 561 may be used for a variety of purposes such as, for example, 
caching and/or storing data, programming instructions, etc. 

The inter&ces 1568 are typically provided as inter&ce cards (sometimes 
5 referred to as "line cards")- Generally, they control the sending and receiving of data 
packets over the network and sometimes support other peripherals used with the 
network device 1 560. Among the interfaces that may be provided are Ethernet 
interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring 
interfaces, and the like. In addition, various very high-speed int^aces may be 

10 provided such as fast Ethernet interfaces. Gigabit Ethernet interfaces, ATM interfaces, 
HSSI interfaces, POS interfaces, FDDI interfiices, ASI interfaces, DHEI interfaces 
and the like. Generally, these interfaces may include ports appropriate for 
communication with the sqppropriate media. In some cases, they may also include an 
independent processor and, in some instances, volatile RAM. The independent 

15 processors may control such communications intensive tasks as packet switching, 
media control and management. By providing separate processors for the 
communications intensive tasks, these interfaces allow the master microprocessor 
1562 to efficiently perform routing computations, network diagnostics, security 
functions, etc. 

20 Although not shown, various removable antemias may be used for further 

increase range and reliability of the access points. In addition, radio transmit power 
e.g., 1, 5, 20, 30, 50, and 100 mW) on the Cisco Aironet -Access Point Series is 
configurable to meet coverage requirements and minimize interference. In addition, a 
Cisco Aironet AP can be configured as a redundant hot standby to another AP in the 

25 same coverage area. The hot-standby AP continually monitors the primacy AP on the 
same chaxmel, and assumes its role in the rare case of a failure of the primary AP. 

Although the system shown in FIG. 12 illustrates one specific network device 
of the present invention, it is by no means the only network device architecture on 
which the present invention can be implementeA For example, an architecture having 

30 a single processor that handles communications as well as routing computations, etc. 
is often used. Further, other types of interfaces and media could also be used with the 
network device. 

Regardless of network device's configuration, it may employ one or more 
memories or memory modules (such as, for example, memory block 1565) configured 
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to Store data, program instructioxis for the general-purpose network operations and/or 
other infoimation relating to the fimctionality of the techniques described herein. The 
program instructions may control the operation of an operating system and/or one or 
more ^plications, for example. 
5 Because such information and program instructions may be employed to 

impl^ent the systems^iethods described herein, the present invention relates to 
machine readable media tibat include program instructions, state information, etc. for 
performing various operations described herein. Examples of machine-readable 
media include, but are not limited to, magnetic media such as hard disks, floppy disks, 

10 and magnetic tape; optical media such as CD-ROM disks; magneto-optical media 

such as floptical disks; and hardware devices that are specially configured to store and 
perform program itistractions, such as read-only memory devices (ROM) and random 
access memory (RAM). The invention may also be embodied in a carrier wave 
travelling over an appropriate medium such as airwaves, optical lines, electric lines, 

IS etc. Bxanoples of program instructions include both machine code, such as produced 
by a compiler, and files containing hi^er level code that may be executed by the 
con^uter using an interpret^-. 

Although illustrative embodiments and qiplications of this invention are 
shown and described herein, many variations and modifications are possible which 

20 remain within the concept, scope, and spirit of the invention, and these variations 
would become clear to those of ordinary skill in the art after perusal of this 
application. For instance, although tiie specification has described the use of a master 
session key, Skey, and a derived session key, Skey*, during initial registration as well 
as re-registration, it is also possible to use a single session key, Skey in the initial 

25 registration process and/or the re-registration process. However, it would then be 
necessary to use the AAA server to refiiesh the Skey. Thus, through the use of both 
the master Skey and derived Skey' it is possible to refi-esh the Skey* without the use 
of the AAA server. Accordingly, the present embodimraits are to be considered as 
illustrative and not restrictive, and the invention is not to be limited to the details 

30 given herein, but may be modified within the scope and equivalents of the appended 
claims. 



23 



wo 2004/049672 



PCTAJS2003/036850 



CLAIMS 

What is claimed is: 

L In a server adq)ted for aufhentication, autfaorizadon, iuid accounting, a method 
of generating a shared key between a Home Agent and a Mobile Node, comprising: 
5 receiving a request message from a Home Agent, the request message 

identifying the Mobile Node; 

deriving key information &om a key or password associated with the Mobile 
Node; and 

sending a reply message to the Home Agent, the reply message including the 
1 0 key information associated with the Mobile Node, thereby enabling the Home Agent 
to derive a shared key to be shared between the Mobile Node and the Home Agent 
fiom the key information. 

2. The method as recited m claim 1, wherein deriving key information 
comprises: 

15 deriving the key information from a second set of key information derived 

fix)m the key or password. 

3. The method as recited in claim 1, wherein deriving key iiiformation 
comprises: 

obtaining tiie derived key information fiom a domain controller or server. 
20 4. The method as recited in claim l,v(dierein the request message is an access 
request message and the reply message is an access reply message. 

5. The method as recited in claim 1, wherein the key or password comprises a 
Windows password associated with the Mobile Node. 

6. The method as recited in claim 5, further comprising: 
25 obtaining the key or password fiom a domain controllCT. 

7. The method as recited in claim 6, wherein obtaining the key or password fix>m 
the domain controller coinprises: 

sending a request to the domain controller for key or password associated with 
the Mobile Node; and 
30 receiving the key or password associated with the Mobile Node from the 

domain controller. 

8. The method as recited in claim 1 , further comprising: 
applying the key information to authmticate the request message. 
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9. The method as recited in claim 1 , wherein the key or password is stored at the 
Mobile Node, tiiereby enabling the Mobile Node to derive the key information from 
the key or password. 

10. In a Home Agent supporting Mobile IP, a metihiod of au&enticating a Mobile 
S Node, comprising: 

receiving a registration request fiom a Mobile Node, the registration request 
identifying the Mobile Node; 

sending a request message to a AAA server, the request message identifying 
the Mobile Node; 

10 receiving a reply message from the AAA server, the reply message including 

key information associated with the Mobile Node; 

deriving a key from the key information, the key being a shared key between 
the Mobile Node and the Home Agent; and 

sending a registration reply to the Mobile Node. 
15 11. The method as recited in claim 10, wherein the registration request includes a 
CHAP challenge and response. 

12. The method as recited in claim 10, wha:ein deriving a key from the key 
information comprises deriving the key from the key information and a CHAP 
challenge and response obtained from ttie registration request. 

20 13. The method as recited in claim 10, wherdn deriving the key and sending the 
registration reply to the Mobile Node are performed when the reply message received 
from the AAA server indicates tiiat the Mobile Node is successfidly authenticated. 
14. The method as recited in claim 10, wherein the request message is an access 
request message and the reply message is an access reply message. 

25 15. The me&od as recited in claim 10, wherein the Mobile Node is to derive the 
shared key from a second set of key information stored at the Mobile Node. 

16. The method as recited in claim 15, whereiu the key information is equivalent 
to the second set of key information. 

17. The method as recited in claim 15, wherein the second set of key information 
30 stored at the Mobile Node is a root key, a password, or a key shared between the 

Mobile Node and the Home Agent in a previous session. 

18. The method as recited in claim 1 7, wherein the registration request includes a 
SPI, replay protection timestamp, and indicates an algorithm to be used to 
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autfaenticate the registration reply, wherein the SFI, the replay protection timestamp, 
and the algorithm are associated with the second set of key information. 

19. The method as recited in claim 18, further comprising: 

installing the derived key, the SPI, the replay protection timestamp, and the 
5 algorithm in a security association. 

20. The method as recited in claim 17, wherein the registration reply includes a 
SPI, rq)Iay protection timestamp> and indicates an algorithm to be used to 
authenticate the registration rq>ly, wherein the SPI, the replay protection timestamp, 
and the algorithm are associated with the second set of key information. 

10 21. The method as recited in claim 10, wherein the registration reply indicates that 
the Mobile Node is to derive the shared key betfveen the Mobile Node and the Home 
Agent. 

22. The method as recited in claim 21, wherein at least one of the presence of one 
or more extensions in the registration reply and an SPI in the registration reply 

IS indicates that the Mobile Node is to derive the shared key between the Mobile Node 
and the Home Agent. 

23. The method as recited in claim 10, wherein the registration request indicates 
that the Home Agmt is to derive the shared key between the Mobile Node and the 

' Home Agent £rom the key information. 
20 24. The method as recited in claim 23, wherein at least one of the presence of one 
or more extensions in the registration request and an SPI in the registration request 
indicates that the Home Agent is to derive the shared key between the Mobile Node 
and tiie Home Agent 

25. The mediod as recited in claim 23, wherein the presence of an authentication 
25 protocol extension in the registration request indicates a protocol to be used to 
authenticate the registration request and derive the shared key. 

26. The method as recited in claim 23, wherein the presence of a session 
key extension and derived session key extension in the registration request indicates 
that both a session key and a derived session key are to be generated and installed. 
30 27. The me&od as recited in claim 26, further comprising: 

receiving a subsequent registration request &om the Mobile Node to refresh 
the derived session key. 

28. The method as recited m claim 27, further comprising: 

authenticating the subsequent registration request using the session key. 

26 



wo 2004/049672 PCT/US2003/036850 
• 

29. The method as recited in claim 27, further comprising: 

sending a subsequent registration reply to the Mobile Node including the 
derived session key e3ctension, wherein the registration reply is to be authenticated by 
the Mobile Node using the session key. 
5 30. The method as recited in claim 1 0, wherein the key information is a previously 
used session key shared between the Mobile Node and the Home Agent. 

3 1 . The method as recited in claim 1 0, wherein the key information is derived 
fix)m a password associated with the Mobile Node. 

32. The method as recited in claim 3 1 , wherein the password is a Windows 
10 password. 

33. The method as recited in claim 10, further comprising: 
driving a subsequent key from the shared key. 

34. The method as recited in claim 33, wherein deriving the subsequent key from 
the shared key is performed wh^ a binding associated with the Mobile Node is 

IS cleared. 

35. The method as recited in claim 34, wherein the binding associated with the 
Mobile Node is cleared upon expiration of the lifetime of the Mobile Node or de- 
registration of the Mobile Node. 

36. In a Mobile Node, a method of registering with a Home Agent siqyportmg 
20 Mobile IP, comprising: 

sending a registration request to the Home Agent; 

receiving a registration reply from the Home Agent, the registration reply 
indicating that the Mobile Node is to derive a key to be shared between the Mobile 
Node and the Home Agent; and 
25 deriving a key to be shared between the Mobile Node and tiie Home Agent 

from key information stored at the Mobile Node. 

37. The method as recited in claim 36, wherein deriving a key from the key 
information comprises deriving the key from the key information and a CHAP 
challenge and response obtained from the registration reply. 

30 38. The method as recited in claim 36, wherein the key information is a root key, a 
password, or a key shared between the Mobile Node and the Home Agent in a 
previous session. 

39. The method as recited in claim 38, wherein the registration request includes a 
SPI, replay protection timestamp, and indicates an algorithm to be used to 
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authenticate the registration request, wherein the SPI, the rq)lay protection timestamp, 
and the algorithm are associated with flie key information. 

40. The method as recited in claim 38, wfaerdn the registration reply includes a 
SPI, rq)lay protection timestaaq), and indicates an algorithm to be used to 

S authenticate the registration reply, wherein the SPI, the replay protection timestamp, 
and the algorithm are associated with the key information. 

41. The method as recited in claim 36, wherein the registration reply indicates 
whether the Mobile Node is to derive the shared key between the Mobile Node and 
the Home Agent, the method further comprising: 

10 determining from the registration reply whether the Mobile Node is to derive 

the key; 

wherein deriving a key is performed when it is determined from the 
registration reply that the Mobile Node is to derive the key. 

42. The method as recited in claim 41, wherein at least one of the presence of one 
IS or more extensions in the registration reply and an SPI in the registration reply 

indicates that the Mobile Node is to derive the shared key between the Mobile Node 
and the Home Agent. 

43. The method as recited in claim 36, wherein the registration request indicates 
that the Home Agent is to derive the shared key between the Mobile Node and Ihe 

20 Home Agent from a second set of key information received by the Home Agent 

44. The method as recited in claim 43, wherein at least one of the presence of one 
or more extensions in the registration request and an SPI in the registration request 
indicates that the Home Agent is to derive the shared key betwem the Mobile Node 
and the Home Agent. 

25 45. A computer-readable medium storing thereon computer readable instructions 
for generating a shared key between a Home Agent and a Mobile Node in a server 
adapted for authentication, authorization, and accounting, comprising: 

instmctions for receiving a request message from a Home Agent, the request 
message identifying the Mobile Node; 
30 instructions for deriving key information from a key or password associated 

with the Mobile Node; and 

instructions for sending a reply message to the Home Agent, the reply 
message including the key information associated with the Mobile Node, thereby 
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enabling the Home Agent to derive a shared key to be shared betcveen the Mobile 
Node and the Home Agent fiom the key mformation. 

46. A server adapted for authentication, authorization, and accountings the server 
being adapted for generating a shared key between a Home Agent and a Mobile Node, 

S comprising: 

a processor, and 

a memory, at least one of the processor and the memory being adapted for: 
receiving a request message from a Home Agent, the request message 
identifying the Mobile Node; 
10 deriving key information from a key or password associated with the Mobile 

Node; and 

sendmg a rq)ly message to the Home Agent, the reply message mcluding ttie 
key infoimation associated with the Mobile Node, thereby enabling the Home Agent 
to derive a shared key to be shared between the Mobile Node and the Home Agent 
IS from the key information. 

47. A server adapted for authentication, authorization, and accounting, the server 
being ad^^ted for generating a shared key between a Home Agent and a Mobile Node, 
comprising: 

means for receiving a request message from a Home Agent, the request 
20 message identifymg the Mobile Node; 

means for deriving key information from a key or password associated with 
the Mobile Node; and 

means for sending a reply message to the Home Agent, the reply message 
including the key infonnation associated with the Mobile Node, thereby enabling the 
25 Home Agent to derive a shared key to be shared between the Mobile Node and the 
Home Agent from the key information, 

48. A computer-readable medium storing thereon computer-readable instructions 
for authenticating a Mobile Node in a Home Agent supporting Mobile IP, comprising: 

instructions for receiving a registration request from a Mobile Node, the 
30 registration request identifying the Mobile Node; 

instructions for sending a request message to a AAA server, the request 
message identifying the Mobile Node; 

mstructions for receiving a reply message from the AAA server, the reply 
message includmg key information associated with the Mobile Node; 
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instructions for deriving a key from the key infoimation, the key being a 
shared key between the Mobile Node and the Home Agent; and 

instructions for sending a registration i^ly to the Mobile Node. 

49. A Home Agent supporting Mobile IP» the Home Agent being adapted for 
5 authenticating a Mobile Node, comprising: 

a processor; and 

a memory, at least one of the processor and the memory being adapted for: 
receiving a registration request from a Mobile Node, the registration request 

identifying the Mobile Node; 
10 sending a request message to a AAA server, the request message identifying 

the Mobile Node; 

receiving a reply message from the AAA server, the reply message including 
key information associated with the Mobile Node; 

deriving a key from the key information, ttie key being a shared key between 
15 the Mobile Node and the Home Agent; and 

sending a registration reply to the Mobile Node. 

50. A Home Agent supporting Mobile IP and adapted for authenticating a Mobile 
Node, comprising: 

means for receiving a registration request from a Mobile Node, the registration 
20 request identifying the Mobile Node; 

means for sending a request message to a AAA server, the request message 
identifying the Mobile Node; 

means for receiving a rq)ly message from the AAA server, the reply message 
including key information associated witii the Mobile Node; 
25 means for deriving a key from the key information, the key being a shared key 

between the Mobile Node and the Home Agent; and 

means for sending a registration reply to the Mobile Node. 

51. A computer-readable medium storing thereon computer-readable instructions 
for registering a Mobile Node with a Home Agent supporting Mobile DP, comprising: 

30 instructions for sending a registration request to the Home Agent; 

instructions for receiving a registration reply from the Home Agent, the 
registration reply indicating that the Mobile Node is to derive a key to be shared 
between the Mobile Node and fbe Home Agent; and 
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instructions for deriving a key to be shared between the Mobile Node and the 
Home Agent fiom key information stored at the Mobile Node. 

52, A Mobile Node adapted for registering with a Home Agent siqpporting Mobile 
IP, comprising: 

S a processor; and 

a memory, at least one of the processor and the memory bemg adapted for 
sending a registration request to the Home Agent; 
receiving a registration reply from the Home Agent, flie registration reply 
indicating that the Mobile Node is to derive a key to be shared between the Mobile 
10 Node and the Home Agent; and 

deriving a key to be shared between the Mobile Node and the Home Agent 
from key information stored at the Mobile Node. 

53. A Mobile Node adapted for registering with a Home Agent supporting Mobile 
IP, comprising: 

15 means for sending a registration request to the Home Agent; 

means for receiving a registration rqply fiom the Home Agent, the registration 
reply indicating tiiat tiie Mobile Node is to derive a key to be shared between the 
Mobile Node and the Home Agent; and 

means for deriving a key to be shared between the Mobile Node and the Home 
20 Agent from key information stored at the Mobile Node. 
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